Modern computing systems such as smartphones, tablets, and other mobile devices enable users to install and run various applications. These mobile applications typically provide a wide range of functionality, such as streaming video, social networking, games, email, instant messaging, weather, navigation, or any other mobile application. An application may be referred to as “native” when the application program code has been developed for use on a particular platform or device.
In various runtime environments, it is possible to modify how a method, function, class, or other such software component maps to the actual code implementation of the component. Sometimes referred to as swizzling, such re-mapping technology allows code associated with one function to be replaced by code associated with another function. This may be useful in the context of making modifications to a user interface of an application, for example. Some implementations of re-mapping technology involve modifying the value of a pointer that points to a location in memory where a method is implemented in code. By changing the value of the pointer, the method can be made to point to other code such that, when the method is called, a different method is employed in its place. The target method that is called in place of the original method is sometimes referred to as a callback function. Such techniques may enable a software development kit (SDK) to make modifications to an application without altering the main program code of the application.
Certain runtime environments provide shared-object libraries containing native-code methods that may be used to perform various functions and features. In some instances, an SDK configured to make real-time modifications to an application might require access to the memory addresses of symbols in the shared-object library in order to modify or block certain native-code methods that would otherwise complicate or prevent the SDK from making these modifications. However, some operating systems could prevent an application from opening a shared-object library, thereby blocking the application from accessing the memory locations of the symbols in the library.
Version 7 of the Android® operating system added just-in-time (JIT) translation of Java™ bytecode into native machine processor code on a method-by-method basis. JIT translation is triggered when a Java method is called frequently, which causes the method to be queued and then translated into native machine code. Once translated, the Android Runtime (ART) switches to using the native machine processor code instead of the Java bytecode whenever that method is subsequently called, which provides an optimization over using the bytecode version of the function.
Overview
Provided herein are techniques to facilitate prevention of just-in-time (JIT) translations of application functions. In at least one implementation, a JIT translation function of an operating system is modified in memory to redirect the JIT translation function to execute alternative code when the JIT translation function is called. When the JIT translation function is called for an application function, the alternative code is executed to determine whether the application function has been modified. When the alternative code determines that the application function has been modified, the JIT translation function is prevented from translating the application function into a native machine code version. When the alternative code determines that the application function has not been modified, the JIT translation function is allowed to translate the application function into the native machine code version.
This Overview is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. It may be understood that this Overview is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.